Instant messaging (IM) is a method and system of live or nearly live communication, over the internet or other electronic network, between two users who are both simultaneously logged on to an IM service provider (IMSP). The IMSP provides access to the network as well as software to facilitate IM between its users. It should be noted that there are generally two types of software: “Client-software” that is downloaded by the end-user (generally this is distributed freely) and “Server-Software” that is not downloaded by the end-user. The Server-Software is the core and the engine of the IMSP. It is the Server-Software behavior that distinguishes IMSPs from one another by offering different compelling features. Typically, users download IM Client-Software that enables them to engage in IM with other users of the same IMSP who have also downloaded the same or compatible software. There are a variety of IMSPs, for example: Wireless Village (WV), AOL, Yahoo!, MSN and ICQ (AOL is a registered trademark of America Online, Inc.; Yahoo! is a registered trademark of Yahoo! Inc.; MSN is a registered trademark of the Microsoft Corporation; and ICQ is a registered trademark of ICQ, Inc.). IM software from one IMSP generally does not enable IM communications with users of another IMSP, since most IMSPs use a proprietary solution.
Typical IM software today includes a first user (for example, user1) downloading the IM Client-Software onto his own computer. The IM software downloaded onto a user's computer is generally referred to as the Client-Software (or more simply as the client), a convention that is continued herein. The client connects to an IMSP server when user1 logs on. The client is pre-configured to know the IP address of the server, so when a user logs in (by entering the username and password) using the pre-downloaded proprietary client, it (the client) requests to connect and authenticate the user to the server. Once the user is authenticated, the server updates the client with a list of buddies and their presence information. The server sends a message back to the user1 client as to which buddies from the user1 generated buddy list are logged on, along with their presence information (such as mood, availability, etc.). The client changes the displayed status on user1's computer to indicate which buddies are logged on. The user1 access, information is also sent by the server to the clients of those logged-on buddies. When user1 wishes to send an IM message to a buddy who is logged on, say user2, user1 clicks or selects the name (IM address) for user2, types or attaches a message in the computer window provided, and sends the message. Because the user1 client has already been provided the presence information for the user2 client, the message from user1 is sent directly to user2.
It can be noted at this point that in IM the sending of the message is not guaranteed, so that if an IM is sent from a source to a destination there is no guarantee that it will reach the destination (although this is rare). Note as well that it may be possible to send a message to an end-user that has not logged into the IMSP server, although the behavior of this feature is server dependent (e.g., Yahoo will save a user's messages until the next time the user logs in, while some other IMSPs may not). Also, note that the message from user1 is not sent directly to user2, it is routed instead through the IMSP Server software.
That is, current IM architecture passes all IM messages through a server, which routes the message. A reply from user2 is transmitted to user1 in like manner. An IM session remains open until one of the users logs off, such as by logging off of his client. That client then signals the IMSP server of the offline status, and the server then notifies the clients of all of the online buddies of that revised status. Note that logging off of a client may be distinguished from closing a client, which may be instead only a change in presence information (e.g., active to idle).
One major limitation has been that users of one IMSP identified by one domain name could not effect IM with users of another IMSP identified by a different domain name. This is because each IMSP has its own proprietary standards on how they pack and unpack messages, standards that are not necessarily enabling of the proprietary standards of others. Some users have overcome this limitation by maintaining accounts in each IMSP in which one of their potential buddies has an account. However, this leads to users having to maintain multiple accounts with multiple login identifiers and passwords, having to maintain open clients for each IMSP a user chooses to monitor during any given session on his computer, and the inability to have an IM ‘conversation’ with two buddies who each use a different IMSP. For example, user1@yahoo.com could engage in IM with user2@yahoo.com, but not with user2@msn.com.
Certain IMSPs advertise an ability to facilitate IM communications between users of only specified domains that differ. For example, Odigo (Odigo is a registered trademark of Odigo, Inc.) asserts on its website (www.Odigo.org) that IM users can access two distinct IMSP's: AIM and ICQ. The specific protocol for facilitating this appears to be proprietary. However, since IM is only enabled between specified domains, it is assumed the service is facilitated by servers associated with each domain acting in concert under a contractual relation between the IMSPs.
For convention with regard to this disclosure, an IM address “username@domainname” is parsed as follows. The characters to the left of the ‘@’ symbol are referred to as the username. The characters to the right of the ‘@’ symbol constitute the domain name or domain, which in this convention includes the top-level domain name for simplicity. IM addresses and parts thereof will be offset herein by underlining for clarity.